In computer science, a virtual machine (VM) is a portion of software that, when executed on appropriate hardware, creates an environment allowing the virtualization of an actual physical computer system. Each VM may function as a self-contained platform, running its own operating system (OS) and software applications (processes). Typically, a hypervisor manages allocation and virtualization of computer resources and performs context switching, as may be necessary, to cycle between various VMs.
A host machine (e.g., computer or server) is typically enabled to simultaneously run multiple VMs, where each VM may be used by a local or remote client. The host machine allocates a certain amount of the host's resources to each of the VMs. Each VM is then able to use the allocated resources to execute applications, including operating systems known as guest operating systems. The hypervisor virtualizes the underlying hardware of the host machine or emulates hardware devices, making the use of the VM transparent to the VM operating system or the remote client that uses the VM.
Communication between the VM and the hypervisor is a key component in any virtualization system. A VM is generally passes requests to the hypervisor to be acted upon by the hypervisor. For example, a request may include a request from the VM to transmit a packet to the host machine or to a network that the host machine is connected to. The ability of the hypervisor to immediately notify a VM that a request passed to the hypervisor from the VM has been handled is advantageous because it allows the hypervisor to continue to receive more requests. This, in turn, keeps processing speed and responsiveness of the VM optimized.
When the hypervisor receives a request from a VM that it manages, it will need to communicate with the VM that it has processed the request. In one case, the hypervisor could handle the request immediately upon receipt and only notify the VM that the request has been handled when the hypervisor is done processing. However, a drawback to this approach is that VMs will be delayed while they are waiting to receive confirmation from the hypervisor that a request has been handled. In addition, the hypervisor will not be able to receive additional requests until it has finished processing prior requests. This will result in slower processing and responsiveness of the virtualization system overall.
Instead of immediately handling a request and then notify a VM, another approach is for the hypervisor to queue the request, notify the VM that the request is handled, and then handle the request in the background. Queuing in this context means retrieving information from the request, which generally should be done first. Using this approach, the hypervisor can continue to receive requests from the VM as the VM believes that the previous requests have been processed. However, a potential for inefficiencies can result due to queue size limitations, which, in turn, limits the number of requests that can be queued. In order to keep receiving requests, the hypervisor may copy requests out of VM memory and into a queue in the hypervisor or host machine memory in order to prevent requests in the VM memory from being overwritten by new incoming requests. However, depending upon the request, there are costs in terms of copying time and memory space.
One current approach to address this copying limitation, which has been utilized in fields other than virtualization, is to limit copying of requests to a size threshold. In other words, performing a copy of a request to memory only if the size of the request is larger than a threshold. If the request is smaller than the threshold size, then the request is queued. However, because requests vary in size (e.g., small requests mixed with large requests), this means that requests may be handled out of order. Out-of-order processing can become complicated for the VM, leading to sub-par VM processing and performance.